chore(storage): add storage benchmark tool for Gaxios refactor comparison#8341
chore(storage): add storage benchmark tool for Gaxios refactor comparison#8341thiyaguk09 wants to merge 19 commits into
Conversation
…sport (googleapis#8283) - Remove Service.ts and common.ts files from handwritten/storage - Migrate remaining functionality to StorageTransport - chore(ci): upgrade conformance tests to Node 18
…otprint against baseline versions
…sport (googleapis#8283) - Remove Service.ts and common.ts files from handwritten/storage - Migrate remaining functionality to StorageTransport - chore(ci): upgrade conformance tests to Node 18
…4856049-gaxios-benchmark
…4856049-gaxios-benchmark
product-auto-label
Bot
added
the
api: storage
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a new benchmarking tool in handwritten/storage/internal-tooling/benchmark.ts along with updated documentation in the README. The tool enables comparative latency and memory benchmarking between the current codebase and a specified baseline NPM version of @google-cloud/storage. Feedback focuses on improving the robustness of dynamic imports for module compatibility, replacing hardcoded values with constants, enhancing type safety by avoiding any[], and refining the throughput calculation logic.
…xible module resolution
| logMemory('After Metadata'); | ||
|
|
||
| // Scenario 3: Download Small File | ||
| console.log('Starting Scenario 3: Download (1KB)...'); |
There was a problem hiding this comment.
Is there a reason for only choosing only 1KB file size? Can we make this parameterized for other file sizes as well ?
There was a problem hiding this comment.
Are there other operations which are affected by the migration ?
Some possible examples: Large file transfers, Resumable uploads. If yes we should be benchmarking them as well to make sure we do not see any regression in them due to the migration
There was a problem hiding this comment.
Is there a reason for only choosing only 1KB file size? Can we make this parameterized for other file sizes as well ?
Introduced the --fileSize option (defaulting to 1024 bytes) in yargs. The file size buffer is now allocated dynamically (Buffer.alloc(argv.fileSize, 'a')), and throughput calculations adapt to the configured file size.
There was a problem hiding this comment.
Are there other operations which are affected by the migration ? Some possible examples: Large file transfers, Resumable uploads. If yes we should be benchmarking them as well to make sure we do not see any regression in them due to the migration
Agreed! Our resumable uploads currently only support/rely on Gaxios, so testing this path is crucial. To support better benchmarking here, I've added a --resumable boolean flag option. Under the hood, runUploadScenario passes this flag to the storage iterFile.save(content, { resumable: argv.resumable }) option, enabling targeted performance testing of resumable uploads.
There was a problem hiding this comment.
What other operations have been impacted by the migration ? Can you extend the benchmarking script to have them as well.
There was a problem hiding this comment.
Hi @Dhriti07,
Great point. I have extended the benchmark.ts script to include Stream Uploads (createWriteStream), Stream Downloads (createReadStream), and List Files (getFiles) alongside the existing standard upload/download and metadata scenarios.
These additions ensure we thoroughly validate the Gaxios transport layer for regressions across all core operations.
…sport (googleapis#8283) - Remove Service.ts and common.ts files from handwritten/storage - Migrate remaining functionality to StorageTransport - chore(ci): upgrade conformance tests to Node 18
thiyaguk09
force-pushed
the
storage-node-18
branch
from
eacb087 to
0c58a9a
Compare
…4856049-gaxios-benchmark
…4856049-gaxios-benchmark
…d resumable uploads while updating transport retry defaults
…sport (googleapis#8283) - Remove Service.ts and common.ts files from handwritten/storage - Migrate remaining functionality to StorageTransport - chore(ci): upgrade conformance tests to Node 18
thiyaguk09
force-pushed
the
storage-node-18
branch
from
0c58a9a to
fe44861
Compare
…4856049-gaxios-benchmark
thiyaguk09
force-pushed
the
storage-node-18
branch
from
fe44861 to
0a4f5ac
Compare
…4856049-gaxios-benchmark
…, and list files scenarios
2 participants
Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:
Fixes #<issue_number_goes_here> 🦕